1 00:00:13,520 --> 00:00:21,590 We'll start with another topic in the U.S. The cross site request forgery also called as SRF crosschecked 2 00:00:21,590 --> 00:00:24,260 request forgery, also known as serious. 3 00:00:24,260 --> 00:00:30,210 Ariff is an attack whereby an attacker tricked the victim and performing actions on their behalf. 4 00:00:30,500 --> 00:00:34,550 The impact of the attack depends on the level of permissions that the victim has. 5 00:00:34,760 --> 00:00:39,900 Such attacks take advantage of the fact that the website completely trusts the user. 6 00:00:40,220 --> 00:00:47,120 Once it can confirm that user is indeed who they say they are on your screen, you can see that the 7 00:00:47,120 --> 00:00:55,460 attacker has crafted his own Yodle and when the user clicks under the URL, the email gets directly 8 00:00:55,460 --> 00:00:59,000 changed without even the user knowing what has happened, actually. 9 00:00:59,180 --> 00:01:02,660 So how are CSIR attacks executer? 10 00:01:03,470 --> 00:01:07,430 There are two parts to executing a charoset request forgery attack. 11 00:01:08,000 --> 00:01:12,410 The first one is tricking the victim to clicking a link or loading a page. 12 00:01:13,100 --> 00:01:16,640 This is normally done through social engineering and malicious link. 13 00:01:17,360 --> 00:01:22,920 The second part is sending a crafted, legitimate looking request from the user's browser to the website. 14 00:01:23,330 --> 00:01:30,020 The request is sent with values chosen by the attacker, including any cookies that the victim has associated 15 00:01:30,020 --> 00:01:30,890 with that website. 16 00:01:31,610 --> 00:01:36,890 This way, the website knows that this victim can perform certain actions on the website. 17 00:01:37,340 --> 00:01:44,150 Any requests and with these HTP credentials or cookies will be considered a legitimate request, even 18 00:01:44,150 --> 00:01:49,460 though the victim would be sending the request of the attackers or on the attackers command. 19 00:01:49,720 --> 00:01:54,970 Consider this example that I walk into a bank and I tell them that I'm you. 20 00:01:55,760 --> 00:01:57,620 I withdraw all of your money. 21 00:01:57,740 --> 00:02:03,820 I've just committed an act of gross human request forgery, and therefore I have your money. 22 00:02:04,340 --> 00:02:11,330 In other words, I pretended to be you and performed an unwanted action on Germany Crossette because 23 00:02:11,330 --> 00:02:17,840 forgery is a type of attack that occurs when a malicious website, email, blog, instant message or 24 00:02:17,840 --> 00:02:24,680 program causes a user's web browser to perform an unwanted action on trustor site for which the user 25 00:02:24,680 --> 00:02:27,140 is currently authenticated to it. 26 00:02:27,210 --> 00:02:33,560 Also pretending to be you or more correctly, doing something with your credentials while you are completely 27 00:02:33,560 --> 00:02:34,180 unaware it. 28 00:02:34,700 --> 00:02:37,910 So let's move ahead to see a side of countermeasures. 29 00:02:38,330 --> 00:02:44,270 The first one is use building or existing a of implementations for self protection. 30 00:02:45,020 --> 00:02:51,230 The synchronizer token defenses have been built into many frameworks we strongly recommended to reset. 31 00:02:51,470 --> 00:02:56,900 The framework you are using has an option to achieve a set of protection by default before trying to 32 00:02:56,900 --> 00:02:58,150 build your custom token. 33 00:02:58,160 --> 00:03:05,560 The rating system, for example, dot net has built in protection that adds a token to seize upon real 34 00:03:05,570 --> 00:03:06,200 resources. 35 00:03:06,950 --> 00:03:12,500 You are responsible for proper configuration, such as key management and token management for using 36 00:03:12,650 --> 00:03:13,280 this building. 37 00:03:13,280 --> 00:03:18,110 See a set of protections that generate tokens to guard, see a set of vulnerable resources. 38 00:03:18,320 --> 00:03:20,870 The next is Synchronizer token pattern. 39 00:03:21,730 --> 00:03:22,530 See yourself. 40 00:03:22,550 --> 00:03:24,860 Tokens should be generated on server side. 41 00:03:25,580 --> 00:03:31,070 They can be generated once per user session or for each request per request. 42 00:03:31,220 --> 00:03:33,620 Tokens are more secure than pulsations. 43 00:03:34,010 --> 00:03:39,740 For example, the back button browser capability is often hindered as the previous page may contain 44 00:03:39,740 --> 00:03:41,330 a token that is no longer valid. 45 00:03:41,780 --> 00:03:48,560 Interaction with this previous page will result in a C srf false positive security even at the server 46 00:03:48,560 --> 00:03:53,510 side implementation token implementation of the initial generation of the token. 47 00:03:53,870 --> 00:03:59,840 The value is stored in the station and is used for each subsequent request until the station expires. 48 00:04:01,050 --> 00:04:06,810 The next, you see a set of tokens should not be transmitted using cookies the CSF have, Copelands 49 00:04:06,810 --> 00:04:13,140 can be added to hidden fields headers and can be used with forms and AJAX calls. 50 00:04:13,920 --> 00:04:18,980 Make sure that the token is not leaked in the server logs or in the user. 51 00:04:20,040 --> 00:04:27,870 The next is encryption, based on the encrypted token Padam leverages and encryption rather than comparison 52 00:04:28,110 --> 00:04:29,230 of the token validation. 53 00:04:29,760 --> 00:04:34,830 It is most suitable for applications that do not want to maintain any state, the server side. 54 00:04:35,280 --> 00:04:43,590 And last, it seems that attribute seems like it is a cookie attribute similar to its GDP, only secure 55 00:04:43,590 --> 00:04:50,730 and minimal, which aims to mitigate severe sort of attacks it has defined in our F.C. six to six forbids. 56 00:04:51,150 --> 00:04:56,150 This attribute helps the browser to decide whether to send cookies along with Charoset requests. 57 00:04:56,460 --> 00:05:01,740 It is important to note that this attribute should be implemented as an additional layer defense. 58 00:05:01,740 --> 00:05:08,490 In concept, this attribute protects the user to the browser supporting it, and it contains as well 59 00:05:08,490 --> 00:05:13,010 two ways to bypass the attribute should not replace having a series of token. 60 00:05:13,320 --> 00:05:19,290 Instead, it should coexist with that token in order to put the user in a more robust way. 61 00:05:19,500 --> 00:05:25,500 I know this is a little bit hard to understand, but if you are really keen to understand what is serious 62 00:05:25,830 --> 00:05:30,830 and how to protect yourself, you can go to the books attached with this course. 63 00:05:31,200 --> 00:05:32,690 See you in the next lecture.